Accelerating Profile Creation

ABSTRACT

Leveraging the wealth of information available on-line to accelerate and facilitate commercial transactions initiated by viewers of television programming, both during conventional programming and while using interactive features such as shopping channels, application channels, executing downloaded applications, and the like, for reducing the amount and frequency of user input required by accelerating and simplifying the process of accessing stored profiles and payment methods in these transactions, and by reducing user efforts in maintaining their on-line presence without compromising user security, is described. The motivation for such simplification derives from concerns apparent in emerging t-commerce transactions, where the means by which viewers may engage in two-way transactions directly in the context of the television programming are different and frequently more constrained than in traditional e-commerce and m-commerce modes.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. Non-Provisional patentapplication Ser. No. 15/608,429 for “System And Method For AcceleratingAccount Creation”, which was filed on May 30, 2017, which is acontinuation of U.S. Non-Provisional patent application Ser. No.14/018,352 for “System And Method For Accelerating Account Creation”,which was filed on Sep. 4, 2013, which claims the benefit of U.S.Provisional Patent Application No. 61/696,783 for “System And Method ForAccelerating Account Creation” filed on Sep. 4, 2012, the entirecontents of all applications are hereby specifically incorporated byreference herein for all that it discloses and teaches.

FIELD OF THE INVENTION

Embodiments of the present invention are directed generally toward thedomain of secure commercial transactions initiated in the context oftelevision programming and carried out over the convergent globalnetwork comprising the Internet, specifically as extended to includecellular networks and the several private television delivery systemsincluding cable, satellite, and IP television, or over another networksuitable for both delivering video programming and carrying TCP/IPcommunications, or during playback of such recorded programming on adevice connected to a TCP/IP network. Embodiments of the invention aredirected specifically towards enabling and accelerating commercialtransactions including, but not limited to, registering user profiles,registering payment methods, and completing purchases, by means ofcreating, storing, sharing, and mining user profile information tominimize requirements to enter alphanumeric characters to complete apurchase and more generally to minimize the number of characters thatare entered to complete purchases.

BACKGROUND OF THE INVENTION

The term e-commerce or electronic commerce typically refers totransactions initiated and completed from a computer device connected tothe Internet. The related terms m-commerce, meaning transactionsinitiated from a mobile telephonic device such as a smartphone, andt-commerce, meaning transactions initiated via television, are gainingcurrency. As in other networking technologies, the concepts ofe-commerce, m-commerce, and t-commerce are convergent and thedifferences among the three are indistinct and variable except withreference to the type of device from which the transaction is initiated.Specifically, the Internet is involved in most t-commerce transactions,and the cellular cloud may be also.

To input credit card or other form of payment information to complete anelectronic purchase can be cumbersome even on a fully-input-enableddevice such as a personal computer. To validate the card information,one must supply the name as it appears on the card, the full billingaddress, the card number, the expiration date, and a security code fromthe reverse of the card. Many smaller e-commerce sites require that thisinput be re-entered for each new transaction to avoid the potentialliability they would incur if they stored it persistently and the sitesecurity were subsequently compromised.

Large e-commerce sites such as AMAZON.COM permit regular users to createaccounts and persistently store not one but several payment methods onthe site. Doing this allows site customers to manage their purchasesmore flexibly and quickly. Customers access this stored information onlyafter logging in via TLS (transport layer security) to a PKI (public keyinfrastructure) certified account, so the probability of a customer'saccount being hacked is reduced unless the customer uses a weak andobvious password. Most high-end e-commerce sites now police against thispractice as well. Storing payment method information with manye-commerce sites has certain disadvantages to the consumer, whichinclude a proliferation of accounts and difficult passwords to remember,or, if the consumer uses the same password for multiple accounts, aheightened security risk.

In the modern arena of multiple electronic media many holders of useraccount information now expose Application Program Interfaces (APIs) bymeans of which other online applications may, with user permission,access and share user profile information. An example of this is anon-line magazine, which allows users wishing to post comments onmagazine articles to log in via FACEBOOK (a separate source ofauthentication and profile data). The poster provides only his email andpassword to authenticate his FACEBOOK account. The magazine thendisplays the authenticated comment with the poster's name, locale, andprofessional title (presuming that the user has not previouslyrestricted access to those data via his FACEBOOK profile). FACEBOOK, inturn, publishes the comment to the poster's Facebook community. Bothapplications, the magazine and FACEBOOK, benefit from enriched content.The poster benefits by not having had to create and maintain a separateprofile with a separate username and password in order to post on amagazine read only occasionally.

Specifically, in the t-commerce world, where the user input device isoften a handheld TV remote controller, providing payment methodinformation to complete a purchase transaction is even more cumbersome.The device is adapted only for entering numeric data and selecting fromsimple menus via navigation and function keys. Creative solutions havebeen devised for allowing alphanumeric input by displaying keyboardimages on the TV screen, but these do not lend themselves to rapid dataentry; they only make alphanumeric entry possible with patience.

SUMMARY OF THE INVENTION

Embodiments of the present invention comprise a database, the “Wallet,”hosted on one or more network-connected servers, that aggregates userprofile information and stores relationships between each user profileand a multiplicity of payment providers and multimedia applications withwhich that user has established accounts. Embodiments of the inventionfurther comprise an extensible collection of interface adapterspermitting uniform transactions between the Wallet and a multiplicity ofother network-hosted applications which expose application programinterfaces (APIs) permitting the exchange of information with otherInternet-hosted applications such as the Wallet. Embodiments of theinvention further comprise a series of methods, collectively referred toas the “TV Wallet” application, for managing a group ofe-commerce/t-commerce/m-commerce related transactions, described below,whether the transactions are initiated through live, time-shifted, oron-demand programming, or other mode of the Video Display Device beingused, and regardless of the type of device upon which the programming isrecorded and/or played. Embodiments of the invention additionallycomprise methods for propagating profile updates and other informationamong the multiplicity of accounts (both payment accounts and personalaccounts) held by the viewer on the multiplicity of Internet-hostedapplications, where permission to do so is recorded by the user in theWallet and authorized by the applications. Embodiments of the inventionfurther permit the viewer to initiate a transaction from a directinterface exposed by the device on which the video programming isplayed, and using that interface, move the transaction to an alternativeweb-connected device where it may be more easily or more privatelyconcluded.

The TV Wallet application exposes a web site of its own which users mayaccess to proactively register, create a profile, and add paymentmethods to their Wallet account by means well-known to one ordinarilyskilled in the art. However, embodiments of the present invention applyto the user interface, methods, and systems by which the TV Walletapplication manages these operations when initiated during theconsumption by a viewer of video programming or other video-basedactivity hosted on the video display device or video delivery systemusing the native interface of the video player, such as an infraredremote control.

The TV Wallet application manages, aggregates, and facilitates a numberof basic transactions. These transactions may be combined into a largernumber of workflows according to the context in which a user interactionoccurs, the requirements of the electronic medium used to initiate thetransaction, the requirements of other participating Internet-hostedapplications, and the user's preferences. The basic transactionsinclude:

-   -   1. Creating a user account profile in the Wallet database;    -   2. Retrieving profile or authentication information from another        application;    -   3. Defining a new payment method to complete a commercial        transaction;    -   4. Choosing a payment method to complete a commercial        transaction;    -   5. Pushing newly gathered information into the TV Wallet        Profile;    -   6. Pushing newly gathered information into one or more data        sources already associated with the Wallet; presuming that the        data source subscribes to such updates;    -   7. Authenticating the user prior to permitting one or more of        the other transactions; and    -   8. Creating linkages between the Wallet database and other        payment vehicles.

The TV Wallet application may offer other features and transactions overand above this list of basic transactions. The above list ofTransactions is specifically called out as the set of commercialservices where Viewer input can be accelerated by embodiments of thepresent invention using the system and methods described.

An embodiment of the invention is the TV Wallet's ability to simplycombine these transactions to provide payment flexibility and maximizeuser satisfaction with the interface without compromising accountsecurity. A new user may initiate the creation of a Wallet account(sign-up) in several contexts, with the workflows associated with eachcontext comprising a distinct set of potential paths through the TVWallet application, appropriate to the context. Typical initiatingcontexts for Wallet creation include:

-   -   Product or Service registration (e.g. Smart TV registration,        Service Operator Registration);    -   Proactive sign-up using any web browser;    -   Sign-up prior to initiating a purchase transaction; and    -   Sign-up after completing a purchase transaction.

Another embodiment of the invention is the TV Wallet's ability tointeract with a variety of e-commerce, t-commerce, and m-commerceapplications for the ultimate purpose of associating a payment methodwith the transaction, in a multiplicity of ways determined by the mediumof interaction, the capabilities of the application programminginterfaces (APIs) exposed by the other applications, the securitypreferences established by the account owner, and other factors.

Yet another embodiment of the invention is the TV Wallet's ability toallow the viewer to indicate via the video device interface his desireto continue the transaction using another web-capable device, typicallya computer, mobile phone, tablet, or similar device, regardless of thenetwork medium, wireless or wired, by which the device connects to thenetwork.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a typical system for initiating commercialtransactions in the context of viewing a television programming,including a typical video device capable of playing and/or recordingtelevision programming, multiple network-capable devices upon whichtransactions initiated during viewing may optionally be concluded, aconverged network by means of which all the illustrated devices maycommunicate with one or more Wallet Agents, the Wallet Server, theWallet Database, and zero or more other web applications with which theWallet Server communicates by means of APIs.

FIG. 2 illustrates the use of the TV Wallet application to create aWallet profile and account, where the transaction is initiated andconcluded from the video display device, and where some profileinformation is obtained from a Product or Service Registry.

FIG. 3 illustrates the use of the TV Wallet to create a Wallet profileand account, where the transaction is initiated from the video displaydevice but concluded on another device.

FIG. 4 illustrates a Wallet Profile Update, where the user authenticatesusing a profile source other than a registry, and then elects to pushupdated information to other profile sources.

FIG. 5 illustrates an accelerated payment transaction, wherein allprofile and payment method information are retrieved from thepurchaser's Wallet.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention are directed generally toward thedomain of secure commercial transactions initiated in the context oftelevision programming and carried out over a convergent network.Embodiments of the invention involve multiple user displays and inputdevices and multiple network protocols, and comprise multiple preferredembodiments especially with regard to the placement of automationintelligence about the host network. The following definitions areprovided as an aid to understanding the subject matter and terminologythereof. Such definitions are not intended to limit the invention as setforth in the claims.

DEFINITIONS

Web-enabled Device (WD): A stored-program computer comprising at least aCPU, a memory where programs and data may be persistently stored, atleast one network interface enabling the device to connect to a networkand carry out two-way interactions with another Web-Enabled Device, andmeans for accepting input from a human being (the “User” or “Viewer”)and displaying output to a human being by visual, auditory, and/ortactile means. A Smartphone, Laptop, and Tablet are all examples of WDs,but many other examples exist.

Server: A Web-enabled Device or a cluster or federation of such devicescapable of hosting applications offering services (Web Services) toclients on the network to which the Server is connected.

Video Display Device (VDD): Any device or aggregation of devices capableof receiving a video transmission, optionally storing one or more videotransmissions, playing video programs directly from the receivedtransmission stream, or with a delay, or from a recording, which furthercontains a stored-program computer and means by which input from a humanViewer may be received, capable of conducting two-way communicationswith the source of the video transmission (in-band) and/or anothernetwork (out-of-band). Some but not all VDDs meet the definition of WebEnabled Device. One example of a VDD is a conventional TV receiver whichhas an infrared remote control and which is attached to a set-top boxcontaining a stored-program computer and an interface to a video serviceoperator's network such as a cable or satellite network. Another exampleof a Video Display Device is a Smart TV which is connected to theInternet or a private TCP/IP network, regardless of whether it is alsoconnected to a set-top box. A third example of a Video Display Device isany Web-enabled Device hosting a stored program capable of playing videostreams received over the network. Many other examples exist.

Video Program: A Video Program includes, but is not limited to,broadcast, streamed, linear or non-linear (Video on Demand or VoD)transmission or the playback of a recording of such a transmission, ofvideo content which can comprise, by example, a TV series, an episode ofa TV series, a commercial, sports series, sports program, music video,or movie. Again, many other examples exist. The Video Program furthercomprises video signals, audio signals, and other meta-informationrelated to the program which may be embedded in the video stream.

Agent: An agent is a computer program which may reside on a multiplicityof stored program computers such as Servers, VDDs and WDs, which bothacts independently and functions as a client of another application.Agents may exist in different embodiments for different host devices,and agent functions may even be divided across multiple hosts. Referringto FIG. 1, an example of dividing an agent is that some embodiments ofthe Wallet Agent 12 comprise a component hosted on a VDD 11 incommunication with a second component hosted on a T-commerce orMulti-Media Platform 13 hosted on a Server. Other embodiments of theWallet Agent may be entirely hosted on a Platform and communicate withthe VDD using only intrinsic capabilities of the VDD via an API exposedby the VDD.

Platform: A computer software application hosted on a Server, storedpersistently on storage or memory available to the Server, and executingon one or more CPUs of the Server. The term Platform may refer also tothe Server and the computer software application functioning as a singleentity.

Application Adapter: A software program used to intermediate between afirst application, which exposes a uniform adapter interface, and asecond application, which exposes a proprietary API. The first programmay communicate with a multiplicity of adapters based on some addressingcriterion such as the URL of the second application. The Adaptersimplifies the logic of the first application by allowing it tocommunicate with all Adapters uniformly. The Adapters encapsulate (orhide) the differences among the second application APIs so that thefirst application need not be concerned with them. Typically, newAdapters can be introduced to the first application without interruptingthe operation of the first or second applications.

System and Workflows

Referring again to FIG. 1, an embodiment of the system of the presentinvention comprises a VDD 11, at least one T-Commerce or Multi-MediaPlatform 13 with a Wallet Agent 12. Typically, the stored-programcomputer which is part of the apparatus of VDD 11 persistently storessome unique identifier for the unit, such as a manufacturer's serialnumber for a Smart TV or Set-top box, or a MAC address, or a static IPv6address, or some other address which persistently and uniquelydistinguishes this particular unit from all other units of the sametype. Means are provided by some manufacturers and service operators onthe VDD 11 for the Wallet Agent to access this unique ID, which willhenceforth be referenced as the TVID. Not all VDDs expose a TVID. Wherethe TVID is available, it can be used as an accelerated means ofauthenticating the viewer. When no TVID is available, otherauthentication means must be provided. In some embodiments of theinvention, the Wallet Agent 12 is hosted entirely on the VDD 11. Inother embodiments, the Wallet Agent is hosted entirely on a Server on orin communication with the T-Commerce or Multi-Media Platform 13. Instill other embodiments, components of the Wallet Agent 12 reside onboth the VDD 11 and the T-Commerce or Multi-Media Platform 13. TheSystem may further comprise one or more WDs 14, some of which may hostan optional App 15 capable of communicating with at least one WalletAgent 12. The system further comprises a Wallet Platform 110 with aWallet Database 111. The Wallet Platform 110 may communicate with amultiplicity of other Web Applications which by means of ApplicationAdapters 112. The other Web Applications are variously classified asProduct/Service Registries 115, Authentication and Profile Data Sources113, and Payment Methods 114. The overlapping circles 115, 113, and 114denote how a single Web Application may belong to one, two, or all ofthe above classifications. Referring again to FIG. 1, the lozenge-shapedelements of the drawing represent individual Web Applications whichbelong to at least one of the above classifications. Application 17 I(i.e., the “Other”) is a Registry 115 which is also a source ofAuthentication and Profile Data 113. Application 18 (i.e., FACEBOOK) isonly a source of Authentication and Profile Data 113. Application 19(i.e., AMEX) is an example of a Payment Method 114 that is neither asource of profile data 113 nor a registry 115.

The convergence of TCP/IP networks exemplified by the Internet withtwo-way video broadcast networks exemplified by cable and satelliteservice providers is not seamless and is in different stages ofintegration in different geographical regions and due to technologicaldifferences among the several video broadcast and on-demand serviceproviders. Thus, the data path taken by an event initiated by a viewerat a VDD may travel in-band to a broadcast head-end of the serviceprovider and from there via a TCP/IP network gateway to the T-Commerceor Multi-Media platform and the Wallet Agent. Alternately, the event maytravel out-of-band, directly over a TCP/IP network from a VDD 11 to aPlatform 13.

Similarly, an embodiment of the system of the present inventioncomprises the many existing and imaginable means by which a Viewerinitiates a transaction from the VDD 11. Examples of such means are anInfrared (I/R) remote control, a touch-screen, gesture-based control,voice activated controls, physical controls on a TV receiver or set-topbox, a wireless or wired game controller, and a keyboard and mouse. Aslong as the Viewer does not activate another WD to initiate theT-Commerce transaction but initiates the transaction by means of aninterface exposed by the VDD itself, the transaction falls within theembodiment of the system of the present invention.

When the T-Commerce or Multi-Media Platform 13 receives an event from aVDD 11 indicative of a Viewer's interest in engaging in a commercialtransaction, the Platform invokes the Wallet Agent 12 to manage thetransaction. The event contains a variable amount of information aboutthe context in which the event was initiated, which may include a TVID,but always includes sufficient addressing information to permit theWallet Agent 12 to formulate and send a response to the initiating VDD11. The information associated with the event may further comprise dataabout the source of the video program being consumed, such as whetherthe program originates from a recording, a broadcast, or an on-demandstream. The information associated with the event may further compriseprogram information such as the name of the series or episode beingconsumed and the time within the episode at which the event wasinitiated. The information associated with the event may furthercomprise data about the source of the video program being consumed, suchas whether the program originates from a recording, a broadcast, astandalone application, or an on-demand stream. The informationassociated with the event may further comprise program information suchas the name of the series or episode being consumed and the time withinthe episode at which the event was initiated, or context data from theapplication. Other types of information may also be included with thetransaction.

Referring now to FIG. 2, which depicts a first use of the TV Walletapplication, where the Viewer has previously registered with his TVservice operator or VDD manufacturer and has a profile with that entity,but does not have a TV wallet profile. In a typical scenario, the Viewerhas been browsing products displayed on the VDD screen, added at leastone product to a virtual shopping basket or similar construct, and nowinitiates a purchase by sending a “checkout” event from VDD 11's viewerinterface. When the Wallet Agent 12 receives the initiating event, ituses the identifying information in the event, if present, such as TVID,to query the Wallet Platform 110 to determine whether an existing WalletProfile in the Wallet Database 111 is associated with the initiating VDD11. Finding no Wallet Profile, but identifying the correct Registry fromthe TVID in the request, the Wallet Platform 110 uses the ID to queryProfile Source 113 to see if a Product/Service profile has beenregistered for VDD endpoint 11. If a profile is found, it is nextdetermined whether the current viewer is the owner of the profile. TheWallet Platform 110 responds to the Wallet Agent 12 by prompting theViewer for his profile password. If the Viewer is the owner of theprofile and knows the password, he provides it, and the Wallet Agent 12forwards the password and previously established ID back to the WalletPlatform, enabling it to retrieve from Profile Source 113 alphanumericprofile information such as the Viewer's name, billing address, andphone number. An indicator that a stored payment method is present mayalso be provided.

Wallet Platform 110 returns the profile information to the Wallet Agent12, which uses it to display on the VDD a partially pre-filled paymentform. Because no stored payment method is available in this example, theViewer must fill in the Credit Card Number, Expiration Date, andSecurity Code. At this point the Viewer might also be offered the optionof moving the transaction to another device, but in the sequence of FIG.2 this does not occur. The Viewer enters the required information andselects Place Order. Wallet Agent 12 returns the collected informationto the T-Commerce Platform 13 which will complete the purchase. Platform13 signals to the Wallet Agent 12 that the purchase was successful.Wallet Agent 12 now offers the Viewer the option of creating a TV Walletprofile to accelerate future purchases by causing the offer to bedisplayed on the VDD 11. If the Viewer accepts the offer (such as bypressing OK on the TV Remote) the Viewer is prompted to confirm themobile phone number for the profile and create a numeric PIN whichbecomes his TV Wallet password. Wallet Agent 12 forwards the profiledata and PIN to Wallet Platform 110, which creates a new Wallet Profilein the Wallet Database 111. The Wallet Profile can be identified by TVIDand PIN when the Viewer initiates transactions from his home VDD 11, sothat the Viewer enters only the PIN to authenticate, or by mobile phonenumber and PIN, which enables the Viewer to access the Wallet Profilefrom other devices, including VDDs belonging to other people and VDDsthat do not expose a unique TVID. When the Wallet Platform 110 signalsWallet Agent 12 that the Wallet Profile has been successfully created,Wallet Agent asks the viewer whether to add the Payment Method just usedto the Wallet Profile. If the Viewer authorizes this action, WalletAgent 12 commands the Wallet Platform 110 to re-validate the paymentinformation with the Payment Source 114. Payment Source 114 returns anapproval token, proprietary to payment source 114, which the WalletPlatform 110 stores in the Wallet Database 111 along with the last 4digits of the card number or some other nickname for the payment method(e.g. “My Gold Amex.”). When the Wallet Platform reports the success ofthis transaction to Wallet Agent 12, the Wallet Agent causes a messagethanking the Viewer for using TV Wallet to display briefly on the VDDand terminates the dialog.

Referring to the above list of basic T-commerce/multi-media transactionssubject to acceleration and facilitation by the TV Wallet application,the sequence of FIG. 2 includes cases of a transaction of Authenticatingthe User, a transaction of Retrieving profile information from anotherapplication, a transaction of Defining a new payment method, atransaction of Creating a user account profile in the Wallet Database, atransaction of pushing newly gathered information into the TV Wallet,and a transaction of creating Linkages between TV Wallet and otherpayment vehicles. Of these, the transaction of Authenticating the User,transaction of Retrieving profile information from another application,transaction of Creating a user account profile in the Wallet Database,transaction of pushing newly gathered information into the TV Wallet,and transaction of creating Linkages between TV Wallet and other paymentvehicles are accelerated by the Wallet Agent's ability to aggregate andre-use information the Viewer has authorized it to access.

Referring now to FIG. 3, the same transaction as in FIG. 2 is described,except that in the sequence of FIG. 3, the Viewer is reluctant to enterthe credit card information on the VDD screen because others are in theroom. As in the sequence of FIG. 2, the Viewer has been browsingproducts displayed on the VDD screen, added at least one product to avirtual shopping basket or similar construct, and now initiates apurchase by sending a “checkout” event from VDD 11's viewer interface.When the Wallet Agent 12 receives the initiating event, it uses theidentifying information in the event, in this case a TVID, to query theWallet Platform 110 to determine whether an existing Wallet Profile inthe Wallet Database 111 is associated with the initiating VDD 11.Finding no Wallet Profile, but identifying the correct Registry from theTVID in the request, the Wallet Platform 110 uses the ID to queryProfile Source 113 to determine if a Product/Service profile has beenregistered for VDD endpoint 11. If a profile is found, it is nextdetermined whether the current viewer is the owner of the profile. TheWallet Platform 110 responds to the Wallet Agent 12 by prompting theViewer for his profile password. If the Viewer is the owner of theprofile and knows the password, he provides it, and the Wallet Agent 12forwards the password and previously established ID back to the WalletPlatform, enabling it to retrieve from Profile Source 113 alphanumericprofile information such as the Viewer's name, billing address, andphone number. An indicator whether a stored payment method is presentmay also be provided.

Wallet Platform 110 returns the profile information to the Wallet Agent12, which uses it to display on the VDD a partially pre-filled paymentform. Because no stored payment method is available, the Viewer mustfill in the Credit Card Number, Expiration Date, and Security Code. Whendisplaying the payment method form, the Wallet Agent 12 can display anindicator that the option of moving the transaction to another device isavailable. For example, overlay phone and envelope icons might bedisplayed, indicating that the transaction can be transferred via SMS oremail. When the Viewer selects the SMS option, the Wallet Agent 12causes the phone number from the profile to be displayed on the TVscreen, prompting the Viewer to OK the use of this mobile phone orcorrect the number. When the Viewer confirms the telephone number, theWallet Agent 12 constructs a mobile web form containing the profileinformation now displayed on the TV screen plus any known informationabout available payment methods, and sends an SMS text containing a URLof the form to the Viewer's confirmed mobile phone, alternate WD 14. TheViewer receives the SMS message and taps the URL to open a mobilebrowser and see the contextually-complete new form. The Viewer entersthe required information easily and privately using the mobile phone'skeyboard or touchpad, and selects Place Order. Submitting the first formfrom the mobile browser causes the Wallet Agent 12 to clear thetransaction artifacts from the VDD 11's display. From this point on, thetransaction proceeds as before, but between the Wallet Agent and themobile phone. Wallet Agent 12 returns the collected information to theT-Commerce Platform 13 which will complete the purchase. Platform 13signals to the Wallet Agent 12 that the purchase was successful. WalletAgent 12 now offers the Viewer the option of creating a TV Walletprofile to accelerate future purchases by causing the offer to bedisplayed on the WD 14. If the Viewer accepts the offer (e.g. by tappingYES) the Viewer is prompted to confirm the mobile phone number for theprofile and create a numeric PIN which becomes his TV Wallet password.Wallet Agent 12 forwards the profile data and PIN to Wallet Platform110, which creates a new Wallet Profile in the Wallet Database 111. TheWallet Profile can be identified by (implied) TVID and PIN when theViewer initiates transactions from his home VDD 11, or by mobile phonenumber and PIN, which enables the Viewer to access the Wallet Profilefrom other devices, including VDDs belonging to other people and VDDsnot capable of providing a TVID. When the Wallet Platform 110 signalsWallet Agent 12 that the Wallet Profile has been successfully created,Wallet Agent asks the viewer whether to add the Payment Method just usedto the Wallet Profile. If the Viewer authorizes this action, WalletAgent 12 commands the Wallet Platform 110 to re-validate the paymentinformation with the Payment Source 114. Payment Source 114 returns anapproval token, proprietary to payment source 114, which the WalletPlatform 110 stores in the Wallet Database 111 along with the last 4digits of the card number or some other nickname for the payment method(e.g. “My Gold Amex.”). When the Wallet Platform 110 reports the successof this transaction to Wallet Agent 12, the Wallet Agent posts aresponse to the WD 14 thanking the Viewer for using TV Wallet andterminates the dialog.

While the sequence of FIG. 3 is described using a mobile phone as thealternate WD and SMS as the transfer protocol, it would be clear to oneordinarily skilled in the art that another protocol native to the WD,such as SMTP (e-mail) can be used just as easily to push the link to thenew form to the alternate WD 14. The use of such protocols does notcompromise the security of the transaction, because no proprietaryinformation needs to be included in the contents of the link sent to thealternate WD, and the link can address a secure HTTPS site where thelanding form requires re-entry of a password or PIN. Further, it will beclear to one ordinarily skilled in the art that rather than having theWallet Agent 12 push the transaction to a WD as in the sequence of FIG.3, an Optional App 15 could be installed on the WD 14 which could pullthe Viewer's in-progress T-commerce transaction from the T-Commerce orMulti-Media Platform 13 and the Wallet Agent 12 using HTTPS or aproprietary secure protocol, the App 15 then continuing the transactionas described.

Referring now to FIG. 4, a transaction where the initiating event doesnot contain a persistent TVID is described. VDD 11 transmits a “GuestCheckout” event as before, but the event does not carry any informationby which the viewer can be identified. This means that unless the Viewersigns in to some profile source, the transaction cannot be completedwithout the Viewer entering his full name and address and paymentmethod. When such a request is received, the TV Wallet applicationoffers via Wallet Agent 12 several options for how to continue,including “Continue as Guest,” “Create TV Wallet,” and “Sign in withFACEBOOK” where “FACEBOOK” 18 is representative of one or moreprofile-providing social applications for which the Wallet Platform 110has Application Adapters 112. The Viewer selects “Sign in with FACEBOOK”and provides a valid (in the sequence of FIG. 4) FACEBOOK 18 usernameand password. Wallet Agent 12 transmits this information to WalletPlatform 110, which attempts an API login to FACEBOOK 18 via Adapter112. The login being successful, the Wallet Platform 110 retrieves theneeded profile information via the Adapter 112. Note that depending onthe details of the API, the permissions the Viewer has set up withFACEBOOK 18, and other factors, the number of request/responseoperations required to do this may vary, as will the amount ofinformation ultimately gathered by the Wallet Platform. When theretrieval sequence is complete, the Wallet Platform 110 returns theprofile data to the Wallet Agent 12, which displays it in apre-populated form on the VDD 11. In this example, the Viewer providesan update to the pre-populated address information via VDD 11. TheWallet Agent continues to communicate with the T-Commerce or Multi-MediaPlatform 13 and a Payment Method 114 to complete the purchase as before.These steps are not shown in FIG. 4 because they are the same as thoseof FIG. 2. When Wallet Agent 12 is notified that the purchase iscomplete, it posts to the VDD 11 an offer to create a TV Wallet Profile,as in FIG. 2. The Viewer responds affirmatively and creates a PIN, soWallet Agent 12 transmits to the Wallet Platform 110 the PIN and some orall of the Payment Method and Profile information, according to theViewer's preferences. Wallet Platform 110 creates a Wallet Profile forthe Viewer, which can be accessed by a Viewer providing a correct PhoneNumber and Pin, or by a FACEBOOK 18 credential. Wallet Platform mayadditionally create a linkage to the Payment Method 114 used in therecent transaction. As a final step, the Wallet Agent queries the Vieweras to whether he wishes his FACEBOOK 18 profile to be updated with therevised address information. In answering affirmatively, the Viewer canspecify whether the update is a one-time update, or whether the TVWallet should always update FACEBOOK 18 when the TV Wallet changes. Theaffirmative by Viewer causes TV Wallet 12 to transmit to the WalletPlatform 110 a permission to update FACEBOOK 18, whereupon the WalletPlatform 110 pushes the update via Adapter 112 to the FACEBOOKapplication 18, concluding the sequence.

FIG. 5 illustrates a purchase transaction where the Viewer haspreviously registered with the VDD manufacturer and created a TV Walletcontaining a linkage to at least one Payment Method. As before, thesequence of FIG. 5 begins when a Viewer, having added at least oneproduct to a virtual shopping basket or other similar mechanism which iswell known to one ordinarily skilled in the art, initiates a “Checkout”event from VDD 11 containing the VDD's TVID. When Wallet Agent 12receives the event, it forwards it to the Wallet Platform 110, whichfinds a Wallet Profile for VDD 11, which may or may not belong to thisviewer. Wallet Platform accordingly instructs the Wallet Agent to offerthe options of continuing as Guest, signing in with TV Wallet, orsigning in with another source of authentication and profile dataapplication 113 (such as FACEBOOK 18) according to the sequence of FIG.4. In the sequence of FIG. 5, the Viewer elects to sign in with TVWallet, providing only the needed 4 to 6-digit numeric PIN. The WalletAgent 12 transmits the PIN to the Wallet Platform, which then retrievesthe Viewer's Profile and list of stored Payment Methods from WalletDatabase 111 and returns them to Wallet Agent 12. Wallet Agent 12formats an overlay that allows the Viewer to confirm or correct billingand shipping addresses and select a payment method. If the Viewer has nocorrections, he has only to select a Payment Method to complete thetransaction from VDD 11. When Wallet Agent 12 receives the selection, itreturns the necessary data to the T-Commerce or Multi-Media Platform 13to complete the transaction as before. In this fully acceleratedsequence, the Viewer has only had to select from a series of choices andprovide a short numeric PIN. By comparison, this transaction is as briefas selecting a Video on Demand movie from one's cable provider.

It will be apparent that many other flows through the system arepossible depending on the initial conditions of the transaction, thenumber and quality of the external profiles the Viewer owns, theViewer's purchasing habits with respect to payment methods, and thepreferences and restrictions imposed on the Wallet Platform by theAdapter APIs and on the Wallet Agent by the host T-Commerce orMulti-Media Platform. However, the methods described herein ofaccelerating registration, authentication, selection, and movingtransactions are applicable to a broad multiplicity of such flows.

The foregoing description of the invention has been presented forpurposes of illustration and description and is not intended to beexhaustive or to limit the invention to the precise form disclosed, andobviously many modifications and variations are possible in light of theabove teaching. The embodiments were chosen and described in order tobest explain the principles of the invention and its practicalapplication to thereby enable others skilled in the art to best utilizethe invention in various embodiments and with various modifications asare suited to the particular use contemplated. It is intended that thescope of the invention be defined by the claims appended hereto.

What is claimed is:
 1. A method comprising: receiving, by a computingdevice, a video display device identifier in a request for a transactionthat is initiated via a video display device by a user; using, by thecomputing device, the video display device identifier to determine aprofile associated with the video display device; receiving, by thecomputing device, authentication information from the user; verifying,by the computing device, the user is an owner of the profile based onthe authentication information; retrieving, by the computing device,profile information from the profile upon authentication; and providing,by the computing device, the profile information to the video displaydevice to allow the video display device to populate a form for thetransaction using at least a portion of the profile information.
 2. Themethod of claim 1, further comprising: receiving an event indicating aninitiation of the transaction on the video display device, the eventincluding the video display device identifier.
 3. The method of claim 2,wherein the event comprises information regarding a video being consumedby the video display device.
 4. The method of claim 1, wherein thetransaction is initiated via a voice control on the video displaydevice.
 5. The method of claim 1, wherein the video display deviceidentifier comprises a television identifier.
 6. The method of claim 1,further comprising: determining that the user does not have a walletbefore determining that the user has a profile, wherein the wallet isused to store payment information for the user; and sending a query toretrieve the profile using the video display device identifier.
 7. Themethod of claim 1, further comprising: receiving purchase informationfor the transaction from the video display device; and creating a walletfor the user that includes payment information that was used in thetransaction for use in another transaction.
 8. The method of claim 7,wherein the wallet is identified by the video display device identifier.9. The method of claim 7 further comprising: receiving an initiation ofanother transaction on the video display device, the another transactionincluding the video display device identifier; determining that thewallet was created for the user; retrieving the payment information fromthe wallet; and providing the payment information to the video displaydevice to allow the video display device to populate another form forthe another transaction using at least a portion of the paymentinformation.
 10. The method of claim 9, wherein the video display deviceuses the profile information to populate the another form for theanother transaction.
 11. The method of claim 1, wherein the profileinformation includes contact information for the user to allow the userto enter payment information on an input device other than the videodisplay device.
 12. The method of claim 1, wherein the transaction isinitiated via a gesture control on the video display device.
 13. Themethod of claim 1, further comprising: creating a wallet for the userthat includes information from the transaction.
 14. The method of claim13, wherein the wallet includes a history of prior transactions for theuser.
 15. A non-transitory computer-readable storage medium containinginstructions, that when executed, control a computer system to beconfigured for: receiving a video display device identifier in a requestfor a transaction that is initiated via a video display device by auser; using the video display device identifier to determine a profileassociated with the video display device; receiving authenticationinformation from the user; verifying the user is an owner of the profilebased on the authentication information; retrieving profile informationfrom the profile upon authentication; and providing the profileinformation to the video display device to allow the video displaydevice to populate a form for the transaction using at least a portionof the profile information.
 16. The non-transitory computer-readablestorage medium of claim 15, wherein the transaction is initiated via avoice control on the video display device.
 17. The non-transitorycomputer-readable storage medium of claim 15, further configured for:determining that the user does not have a wallet before determining thatthe user has a profile, wherein the wallet is used to store paymentinformation for the user; and sending a query to retrieve the profileusing the video display device identifier.
 18. The non-transitorycomputer-readable storage medium of claim 15, further configured for:receiving purchase information for the transaction from the videodisplay device; and creating a wallet for the user that includes paymentinformation that was used in the transaction for use in anothertransaction.
 19. The non-transitory computer-readable storage medium ofclaim 15, further configured for: receiving an initiation of anothertransaction on the video display device, the another transactionincluding the video display device identifier; determining that thewallet was created for the user; retrieving the payment information fromthe wallet; and providing the payment information to the video displaydevice to allow the video display device to populate another form forthe another transaction using at least a portion of the paymentinformation.
 20. An apparatus comprising: one or more computerprocessors; and a non-transitory computer-readable storage mediumcomprising instructions, that when executed, control the one or morecomputer processors to be configured for: receiving a video displaydevice identifier in a request for a transaction that is initiated via avideo display device by a user; using the video display deviceidentifier to determine a profile associated with the video displaydevice; receiving authentication information from the user; verifyingthe user is an owner of the profile based on the authenticationinformation; retrieving profile information from the profile uponauthentication; and providing the profile information to the videodisplay device to allow the video display device to populate a form forthe transaction using at least a portion of the profile information.